@falquaddoomi Can you take a look at this? The main changes of note are in orcid.py, and the more possibly questionable changes involve issue #258. Summary: not sure which ORCID API fields to use. It returns a lot of confusing and duplicate fields, their documentation is insufficient, and there's basically no one I can contact to clarify. We have one data point (Andrew Su) where these changes match their expectations, and one data point (Casey Greene) where these changes don't produce any different results.

Hey @vincerubinetti; agreed, the ORCID API docs leave a lot to be desired.

Regarding issue #258, I think I was able to replicate the behavior Andrew reported with a publication in my ORCID account that has three sources: changing the preferred source changed the order of the elements in work-summary for the publication's group, as well as changing the display-index for that source. There's a bit from the ORCID API tutorial on the display index (https://info.orcid.org/ufaqs/how-are-items-grouped-together-in-an-orcid-record/):

Our API provides support for this in the XSD. Each item has a display index attribute which indicates its rank within its group. The highest display index is the preferred item selected by the researcher, items added via the API which have not been ranked by the researcher have a display index of 0. The display index also determines the work order when reading the ORCID record.

I don't know if that's enough to resolve that issue, but I hope it helps.

That's great, thanks for testing that out. None of my ORCID entries had multiple work summaries to test that with. With that extra data point, I feel confident enough that the api will do what it says (user-specified preferred sources become the highest display-index, and api returns in display-index order) and that this is the right decision.

@andrewsu Do you have time to give this code a quick look and these set of issues one last think?